The newly added block uses spaces for indentation, which is inconsistent with the rest of the file that uses tabs. Additionally, for consistency with the change made on line 449, it is recommended to use the raw() method instead of the magic property raw. The spacing inside parentheses is also inconsistent with the existing codebase.

		$this->_lexer->next();

		// Loop until we find a flag in peak-ahead
		while ($this->_lexer->valid()) {
			$value = $this->_lexer->current();
			array_push($values, $value->raw());

			if (!$this->_lexer->end() && !$this->_lexer->peek->isValue) {
				break;
			}
			$this->_lexer->next();
		}

The line() function is missing the variadic ...$args parameter in its signature and docblock. This is inconsistent with the updates made to out(), out_padded(), and err(), and may cause issues with static analysis (PHPStan) when the function is used with formatting arguments.

/**
 * Prints a message to `STDOUT` with a newline appended. See `\cli\out` for
 * more documentation.
 *
 * @param string $msg Message to print.
 * @param mixed  ...$args Either scalar arguments or a single array argument.
 * @return void
 * @see cli\out()
 */
function line( $msg = '', ...$args ) {

In the constructor path where $rows === array() (hash-table rows passed via $headers), $headers is converted to a numeric list of column names (array_map on $keys), while $safe_rows preserves the original associative keys from each row. This can leave header row widths keyed by integers and data row widths keyed by strings, causing misaligned output / undefined width indexes in renderers. Preserve the original keys (e.g., build $headers as an associative array mapping each key to itself, and ensure rows are normalized to the same key set/order).

render() always pushes the results of _renderFlags() / _renderOptions() into $help, but those methods can return null. join("\n\n", $help) will then introduce leading/trailing blank sections when only flags or only options exist. Filter out null/empty sections before joining (e.g., array_filter with static fn($v) => $v !== null && $v !== '').

Casting the calculated speed to an (int) results in a loss of precision. The $_speed property is typed as float|int, and a float value would be more accurate for representing speed (e.g., items per second). Was this truncation intentional? If so, it would be good to document it. Otherwise, I'd suggest removing the cast to return the more precise float value.

return $this->_speed;

Casting the estimated time to an (int) truncates the value, which could be misleading. The round() function already returns a float, which provides a more accurate estimation. I'd recommend removing the (int) cast to avoid this loss of precision.

return $estimated;